In many communications networks, the communication protocol foresees a “Negative-Acknowledgment” (NACK) protocol message sent to negatively acknowledge or reject a previously received message, or to indicate some kind of error. Wherein acknowledgement (ACK)-based communication networks positively acknowledge receipt of messages, e.g. the Transmission Control Protocol (TCP) is an example of an ACK-based protocol, other protocols are NACK-based, meaning that they only respond to messages if there is a problem. Examples include most reliable multicast protocols which send a NACK when the receiver detects missing packets. An exemplary system providing ACK and NACK indicators is described in US 2009/0109917.
However, sometimes a device may not be able to send or receive such ACK/NACK protocol messages, or be very limited in their ability to do so. For instance, in network systems according to—but not limited to—the ZigBee specification, especially the ZigBee Green Power (GP) specification, resource restricted devices, such as ZigBee Green Power Devices (ZGPD) may only be powered by batteries with small capacity or by energy harvesting. Such devices are heavily restricted in the available amount of energy, which limits their offered functionality and influences the network operation, commissioning and maintenance. Thus, a resource restricted device can often transmit and/or receive only at unscheduled opportunities, e.g. after it has been actuated by a user. One example of such a resource restricted device is a battery-less switch that can only transmit for a short time once it has been actuated by a user, but has no reception capability. Another example of a resource restricted device is a battery-less switch that can receive for a short time once it has transmitted a signal upon actuation by a user. Yet another example of a resource restricted device is a periodically-reporting sensor, harvesting energy from its environment, e.g., by means of a photovoltaic cell, with or without reception capabilities. The amount of energy harvesting performed by an energy harvesting resource restricted device is usually optimized for application specific needs and/or user requirements. For example, for energy-harvesting pushbutton switches, activated by a user operation, the force and depth required to actuate a switch button (i.e. how hard and far the user has to press) are an important acceptance factor. As benchmark conventional systems may be used for mechanically switching mains power. Switch buttons in a mechanically switching mains power network may be operated rather effortlessly. In order to provide such effortless operation, the amount of energy harvested by a switch button is rather small. Thus, even though the GP specification offers bidirectional communication functionality, some user-operated devices, in particular energy-harvesting devices may not have the energy budget to use it.
The bidirectional communication with a ZGPD included in the GP specification is dedicated to sending a message to the ZGPD in a short time window that closely follows the sending of a broadcast packet by the ZGPD. The ZGPD is only able to receive a message during this time window. The destination device(s), i.e. the devices controllable by the ZGPD, select(s) a TempMaster from among the device forwarding a Green Power Device Frame (GPDF) with sequence number N and a flag enabling receiving after transmitting (RxAfterTx=true). The devices forwarding the GPDF can be proxy devices, i.e. device dedicated to multi-hop communication extension between the ZGPD(s) and the destination device(s) and/or the destination devices capable of forwarding. The TempMaster deliver(s) the message to the ZGPD, in the original GP specification (at least) 5 ms, in the current GP specification between 20 and 25 ms, after the reception of the next GPDF (sequence number >=N+1) with RxAfterTx=true. Thus, there is a delay between the message generation and message delivery. This mechanism was meant to be used for infrequent events, like channel or key update. But it was not meant for an acknowledgement, with the acknowledgement acting as a signal to the ZGPD that communication failures of a certain type are currently absent. Assuming now a very tight energy budget, it is often preferred to spend the available energy on several attempts of transmission (in broadcast mode—i.e. to multiple potential receivers), rather than on (sending in unicast mode to a particular receiver and) waiting for an acknowledgement, since the system may have no energy to act upon lack of acknowledgement at the timeout and since in most wireless systems, listening has the same, or even higher, cost as/than transmitting.
Even if enough energy is available to listen for acknowledgements, there are still issues to take into account. For instance, a device may miss a single expected ACK due to: temporary channel fading, short-duration noise, long-duration noise, network changed channel, network changed security key, the previous TempMaster is no longer in range, due to movement of the TempMaster and/or the ZGPD, etc. If the cause is temporary channel fading, the best recovery strategy is to re-send the signal on the same channel, when there is still energy available. If the network changed the security key, the best strategy may be to start a key recover procedure, such as a commissioning procedure. This may require several communication steps and/or user involvement. If the cause is that the network changed channel, the best strategy is to search all channels until the network channel is found again. However, scanning all channels may require a lot of energy, such that the decision to start a channel search should not be taken lightly. If multiple ACKs are missed in a row, the device may exclude some short-term causes first. However, the problem of deciding when to give up re-trying and enter a channel search process remains. Thus, it would be beneficial if an extra signal was available, beyond the missing of several ACKs, by which the device can unambiguously detect a particular type of communication failure.
Accordingly, the transmit-only-behaviour with a plurality of retries is fine as long as the GPDF non-reception is caused by a temporary problem, like interference, fading (which will disappear by themselves) or portability/proxy switching (which will be resolved by the GP network protocol, automatically configuring new proxy devices). However, if the network parameters (e.g. key, channel) have changed during a period of time in which the resource restricted device was not operational, the resource restricted device will have no means of discovering the parameter change, esp. a channel change. In such a case, even the network will most likely not have means for discovering the problem, since it will no longer receive the resource restricted device's messages on the old channel, in particular, if the device is communicating aperiodically (e.g. a user operated device, such as e.g. a light switch, or a device whose transmission intervals depend on the amount of energy available (harvested), e.g. a sensor powered by a small solar cell, or flow). In such constellations, the system does not know when to expect any message from the resource restricted device and therefore cannot reliably detect when it is lost.